1. Field of the Invention
The present invention is generally related to broadband communications systems. More particularly, the present invention is related to broadband communication systems that use Data Over Cable Service Interface Specification (DOCSIS) or any of its derivatives.
2. Background
In DOCSIS related broadband communications architectures, data is transferred between a central location and many remote subscribers. The central location may be referred to as a headend for cable systems, a wireless access termination system (WATS) for broadband terrestrial fixed wireless systems, or a satellite gateway for two-way satellite systems. Subscriber equipment may be referred to as a cable modem (CM) for cable systems, a wireless modem (WM) for broadband terrestrial fixed wireless systems, or a satellite modem (SM) for two-way satellite systems.
In a two-way satellite system, the communication path from the satellite gateway to the SM is called the downstream. The communication path from the SM to the satellite gateway is called the upstream.
Each SM is provided with one or more service identifiers (SIDs) and an address for identification purposes. Present DOCSIS protocol requires the upstream channel to be divided into a stream of mini-slots. The satellite gateway generates the time reference for identifying these mini-slots and controls access to these mini-slots by the SMs. The start time and duration of each mini-slot is relative to a master reference maintained by the satellite gateway. The master reference is distributed to the SMs via SYNC and upstream channel descriptor (UCD) packets. SMs may issue requests to the satellite gateway for upstream bandwidth. The satellite gateway must transmit an allocation MAP on the downstream channel defining the allowed usage of each mini-slot. For example, the satellite gateway may grant a plurality of contiguous mini-slots to an SM to transmit data. The SM must, in turn, time its transmission so that the satellite gateway receives it in the time reference specified.
The allocation MAP is a variable length MAC management message that is transmitted by the satellite gateway to the SMs to define transmission opportunities on the upstream channel. The allocation MAP includes a fixed-length header and a plurality of information elements (IEs). Each information element defines the allowed usage for a range of mini-slots. A Request IE indicates an upstream interval in which SMs may request bandwidth for upstream data transmission. In an embodiment, this may be an invitation for SMs to contend for bandwidth requests.
An SM will receive the allocation MAP and scan it for request opportunities. During a contention transmit opportunity, the SM will transmit a request for the number of mini-slots needed to accommodate a PDU (protocol data unit) that the SM desires to send. After the contention transmission, the SM will wait for a Data Grant (Data Grant Pending) or Data Acknowledge in a subsequent allocation MAP. Once the Data Grant or Data Acknowledge is received, contention resolution is complete.
In many instances the request during a contention transmission may collide with requests from other SMs and be lost. The SM will be on notice that the contention transmission was lost (i.e., a collision occurred) when a subsequent allocation MAP includes an ACK time indicating that the request would have been received and processed, yet fails to include an acknowledgment of the request. The SM must then perform a back-off algorithm, such as, for example, a binary exponential back-off algorithm, and retry. Often times multiple collisions occur causing the SM to have to backoff several times before bandwidth is allocated or until the maximum number of retries has been reached. If the maximum number of retries is reached without bandwidth being allocated, the PDU is discarded.
Two-way satellite communications systems posses a half second round trip delay. If continuous collisions occur for an SM during a bandwidth request, the round-trip delays accumulate, thereby consuming a considerable amount of time. As a result, undesired lags in service will occur. Also, in cases where a large number of subscribers are on these channels, one would not want to devote large amounts of resources to these request regions.
In other applications, it might be desirable for the satellite gateway to receive information about the status of a downstream transmission received by a given subscriber. For example, to implement an adaptive modulation scheme, such information could be used to match SMs with appropriate downstreams. Useful state of health information might include, but is not limited to, downstream codeword error rates (CER) and signal-to-noise ratio (SNR).
One could provide such information to the satellite gateway via a high level protocol, such as SNMP (Simple Network Management Protocol), or via other network management communication methods where each SM is periodically polled for the information. Upon receiving the information, network management would then update a database that stores such information. The down side to such methods is that they require a great deal of processor power and consume both upstream and downstream bandwidth. For example, bandwidth would be utilized to make the request for information to each SM on the downstream and the satellite gateway would have to retrieve the information coming upstream by parsing an entire IP stack.
Therefore, what is needed is a mechanism for providing information about the status of a downstream transmission received by a given subscriber that does not require a great deal of processor power. Also what is needed is a mechanism for enabling bandwidth requests that are not subject to contention.